lectures.alex.balgavy.eu

Lecture notes from university.
git clone git://git.alex.balgavy.eu/lectures.alex.balgavy.eu.git
Log | Files | Refs | Submodules

index.md (3161B)


      1 +++
      2 title = "Transport: elements of transport protocols"
      3 +++
      4 
      5 # Transport: elements of transport protocols
      6 **Elements of transport protocols**
      7 Addressing
      8 
      9 - NSAP (network service access point) — IP address
     10 
     11 - TSAP (transport service access point) — port
     12 
     13 - some services are always on the same ports (e.g. mail server on TCP 25, ssh on TCP 22)
     14 
     15 - portmapper process
     16 
     17     - finds TSAP port for a specified service name, using its database
     18 
     19     - a new service registers itself with the portmapper
     20 
     21     - kind of like directory assistance phone operator
     22 
     23 - initial connection protocol
     24 
     25     - each machine that offers services has a process server (inetd on UNIX)
     26 
     27     - this acts a proxy for less used servers
     28 
     29     - listens to set of ports at same time, waiting for a conn request
     30 
     31 Connection establishment
     32 
     33 - using sequence numbers for packets
     34 
     35     - label packets with sequence numbers that will not be reused within T seconds
     36 
     37     - packet hop limit used to remove old packets
     38 
     39     - time-of-day clock used to choose sequence number
     40 
     41 - three-way handshake
     42 
     43     - one peer checks with other if connection request is current
     44 
     45     - e.g. host 1 chooses sequence number x and sends it in CONNECTION REQUEST to host 2, host 2 replies with ACK containing its own sequence number y, host 1 acknowledges host 2’s sequence number in first data segment it sends
     46 
     47 Connection release
     48 
     49 - asymmetric release — one host gtfo, other host is left hanging. can lead to data loss.
     50 
     51 - symmetric release — participants agree to end connection
     52 
     53     - two-army problem — one white army vs two blue armies. one white beats one blue, but two blue beat white if attack at same time. can they coordinate attack using messengers? No.
     54 
     55 ![screenshot.png](c6172285cec67f33fb8c2039e310b004.png)
     56 
     57 - one way to semi-solve this is by timers and only allowing a certain number of timeouts, but y’know…it’s not great
     58 
     59 ![screenshot.png](d9c9078b869365c6b6a763b48972949d.png)
     60 
     61 Flow control
     62 
     63 - slow down sender if receiver can’t handle the data rate
     64 
     65 - received packets are buffered at the receiver
     66 
     67 - buffer management is done separately
     68 
     69 - available buffer space is receiver window size
     70 
     71 Crash recovery
     72 
     73 - recovery from layer N crash can only be done by layer N+1 (higher abstraction)
     74 
     75 - but only if layer N+1 has info that lets it reconstruct previous state
     76 
     77 - e.g. if there’s a problem on the transport layer, the transport layer’s lazy ass leaves it to the application layer to fix its problems
     78 
     79 Congestion control
     80 
     81 - needed to slow down sender if network can’t handle the data rate
     82 
     83 - bandwidth allocation
     84 
     85     - max-min fairness
     86 
     87         - maximises minimum bandwidth, then uses excess where possible
     88 
     89         - bandwidth given to one flow can’t be increased without decreasing bandwidth to another flow
     90 
     91     - amount of bandwidth needed for a connection varies, so need to converge to ideal point
     92 
     93     - sharing bandwidth between users
     94 
     95     - dynamic adjustments with AIMD — convergence:
     96 
     97 ![screenshot.png](7ed3a24108f8c995218a9102a639cf47.png)
     98 
     99 - problem is, TCP data loss means congestion, and wireless loses data commonly. so wireless must mask data loss